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HOFF, Administrative Patent Judges. 

JEFFERY, Administrative Patent Judge. 

DECISION ON APPEAL 
Appellants appeal under 35 U.S.C. § 134 from the Examiner's 
rejection of claims 1-13. We have jurisdiction under 35 U.S.C. § 6(b). We 
affirm-in-part and enter a new ground of rejection under 37 C.F.R. 
§ 41.50(b). 
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STATEMENT OF THE CASE 
Appellants invented a method for configuring a scan driver for 
controlling scan jobs directed to a scan peripheral. The driver may be 
embodied in a dedicated peripheral server. Based on a stored capability 
descriptor obtained from the peripheral and scanning parameters, the scan 
driver is configured by linking various driver modules. 1 Claim 1 is 
illustrative: 

1 . A program for interfacing a client computer to one or more scan 
peripheral devices, the program comprising functions for: 

querying a scan peripheral for a capability descriptor; 

determining whether an appropriate capability descriptor is obtained 
in response to said step of querying; 

storing a capability descriptor associated with a scan peripheral for 
which an appropriate information capability descriptor has been received as 
determined in said step of determining; 

configuring a scan driver for a scan job for a scan peripheral when a 
scan job is requested by a client by a set of pre-stored driving modules, a set 
of pre-stored driving modules being selected according to user set 
parameters in the scan job and capabilities indicated in a stored information 
capability descriptor concerning scan peripheral to which the scan job is 
directed. 

The Examiner relies on the following prior art reference to show 
unpatentability: 

Lo US 5,911,044 Jun. 8, 1999 



1 See generally Spec. 2:14-3:21. 
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1. Claim 1 stands rejected under 35 U.S.C. § 101 as being directed to 
non- statutory subject matter. 2 

2. Claims 1-13 stand rejected under 35 U.S.C. § 102(b) as being 
anticipated by Lo. 

Rather than repeat the arguments of Appellants or the Examiner, we 
refer to the Briefs and the Answer 3 for their respective details. In this 
decision, we have considered only those arguments actually made by 
Appellants. Arguments which Appellants could have made but did not make 
in the Briefs have not been considered and are deemed to be waived. See 37 
C.F.R. § 41.37(c)(l)(vii). 

OPINION 

The Rejection Under §101 
We first consider the Examiner's rejection of claim 1 under § 101. 
The Examiner indicates that claim is directed to functional descriptive 
material that does not reside on a computer-readable medium. As such, the 
Examiner contends, the claim merely recites a computer program that does 
not define any structural or functional interrelationships between the 
computer and the program to enable the program's functionality to be 
realized (Ans. 3). 

2 This rejection was indicated in the Answer as a new ground of rejection 
(Ans. 3). Although the Brief presents arguments directed to a previous 
rejection of claim 8 under § 101 (App. Br. 3), the Examiner did not reject 
claim 8 under § 101 in the most recent Answer. Rather, the § 101 rejection 
in the most recent Answer is limited solely to claim 1 . 

3 We refer to (1) the most recent Brief filed October 14, 2005; (2) the most 
recent Answer mailed August 3, 2007; and (3) the Reply Brief filed 
February 27, 2006 throughout this opinion. 
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Appellants argue that claim 1 does not define a data structure, but 
rather defines process steps. These process steps, Appellants contend, 
render claim 1 statutory under § 101 since the claim requires one or more 
acts to be performed on a physical device, namely a scan peripheral (Reply 
Br. 2). 

At the outset, we note that the preamble of claim 1 clearly and 
unambiguously recites a program. Specifically, the preamble recites "[a] 
program for interfacing a client computer to one or more scan peripheral 
devices, the program comprising functions for...." (emphasis added.) 

The issue before us, then, is whether Appellants have shown that the 
Examiner erred in concluding that the program recited in claim 1 does not 
recite statutory subject matter under § 101. For the following reasons, we 
find Appellants have shown no such error. 

"Functional descriptive material consists of data structures and 
computer programs which impart functionality when employed as a 
computer component." Manual of Patent Examining Procedure § 2106.01, 
Rev. 6, Sept. 2007 ("MPEP") (emphasis added). Functional and non- 
functional descriptive material, however, are both nonstatutory when 
claimed as descriptive material per se. Id.; see also In re Warmerdam, 33 
F.3d 1354, 1360 (Fed. Cir. 1994). 

"When functional descriptive material is recorded on some computer- 
readable medium, it becomes structurally and functionally interrelated to the 
medium and will be statutory in most cases since use of technology permits 
the function of the descriptive material to be realized." MPEP § 2106.01 
(emphasis added). Compare In re Lowry, 32 F.3d 1579, 1583-84 (Fed. Cir. 
1994) with Warmerdam, 33 F.3d at 1361. 
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It is this distinction between (1) the functional descriptive material per 
se, and (2) recording such functional descriptive material on a computer- 
readable medium that is critical to patentability under § 101. As functional 
descriptive material, this distinction applies both to computer programs and 
data structures. 

As the MPEP explains: 

[C]omputer programs claimed as computer listings 
per se, i.e., the descriptions or expressions of the 
programs, are not physical 'things.' They are 
neither computer components nor statutory 
processes, as they are not 'acts ' being performed. 
Such claimed computer programs do not define 
any structural and functional interrelationships 
between the computer program and other claimed 
elements of a computer which permit the computer 
program' s functionality to be realized. In contrast, 
a claimed computer-readable medium encoded 
with a computer program is a computer element 
which defines structural and functional 
interrelationships between the computer program 
and the rest of the computer which permit the 
computer program's functionality to be realized. 

MPEP § 2106.01(1) (emphasis added). 

With these principles in mind, we turn to claim 1 on appeal before us. 
Interpreting claim 1 as a whole, 4 claim 1 merely recites a program 
comprising functions for (1) querying a scan peripheral; (2) determining 
whether an appropriate capability descriptor is obtained responsive to the 



4 See Diamond v. Diehr, 450 U.S. 175, 188 (1981) ("In determining the 
eligibility of respondents' claimed process for patent protection under § 101, 
their claims must be considered as a whole."). 
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querying; (3) storing a capability descriptor; and (4) configuring a scan 
driver. 

Since claim 1 merely recites a program per se with certain recited 
functions, we agree with the Examiner that the claim, in effect, recites 
functional descriptive material. Since this functional descriptive material is 
not recorded on a computer-readable medium, it is therefore non- statutory 
subject matter under § 101. 

While the recited functions may relate to acts to be performed as 
Appellants argue (Reply Br. 2), they are merely functions of the program - 
not concrete acts being performed akin to process claim steps. Indeed, the 
MPEP all but confirms this point. See MPEP § 2106.01(1) ("[Computer 
programs] are neither computer components nor statutory processes, as they 
are not 'acts' being performed, .") (emphasis added.) As such, the fact that 
the claimed program has such intended functions does not somehow impart a 
structural and functional interrelationship between the program and other 
elements of a machine or computer which permit the program's functionality 
to be realized. 

Therefore, Appellants' arguments pertaining to claim 1 reciting acts to 
be performed on a physical device are unavailing as they are germane to 
process claims — not claims directed solely to functional descriptive material 
as is the case here. As noted above, Appellants' arguments are relevant only 
with respect to the recited program' & functionality — not any actual concrete 
steps that would be recited in a process claim. To adopt Appellants' 
argument would render the prohibition against claiming programs per se 
(i.e., functional descriptive material) under § 101 meaningless, as virtually 
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all programs have some sort of functionality when executed. That is the 
very essence of functional descriptive material. 

That said, we note that if the word "program" were replaced with 
"process" in the preamble of claim l, 5 we would have an entirely different 
situation: the claim would easily pass muster under § 101. In this situation, 
the claim would clearly recite a process with concrete steps to be performed 
in the body of the claim. But as a "program," claim 1 on appeal before us 
merely recites nonstatutory functional descriptive material per se, and is 
therefore unpatentable under § 101. 

For the foregoing reasons, Appellants have not persuaded us of error 
in the Examiner's rejection of claim 1 under § 101. Therefore, we will 
sustain the Examiner's rejection of that claim. 

The Anticipation Rejection 
We now consider the Examiner's anticipation rejection of claims 1-13 
over the disclosure to Lo (Ans. 4-8). Anticipation is established only when a 
single prior art reference discloses, expressly or under the principles of 
inherency, each and every element of a claimed invention as well as 
disclosing structure which is capable of performing the recited functional 
limitations. RCA Corp. v. App. Digital Data Sys., Inc., 730 F.2d 1440, 1444 
(Fed. Cir. 1984); W.L. Gore and Assoc., Inc. v. Garlock, Inc., 721 F.2d 1540, 
1554 (Fed. Cir. 1983). 



5 Converting claim 1 into a process claim in this manner would also require 
deleting the term "functions for" in line 2 of the preamble. 
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Independent Claims 1, 8, and 13 

Regarding independent claims 1, 8, and 13, Appellants argue that the 
Examiner's rejection is improper since the Examiner unreasonably 
interpreted the recited "pre-stored driving modules" (claim 1); a stored "set 
of driver modules" (claim 8); or a "set of scan drive modules" (claim 13) as 
corresponding to the scan parameters disclosed in Lo. Appellants 
emphasize that the intrinsic evidence indicates that the broadest reasonable 
interpretation of scan drivers is clearly different from scan parameters in 
light of the terms' ordinary meaning. To support this contention, Appellants 
refer to three sources of intrinsic evidence: (1) the Specification; (2) the Lo 
reference itself; and (3) the claims on appeal (App. Br. 4-7; Reply Br. 4). 

First, Appellants argue that the Specification expressly indicates that a 
driver "functions to control a scan job from a particular peripheral according 
to the capabilities and protocol for the particular peripheral" (App. Br. 6). 
Appellants emphasize that the Specification makes clear that an 
automatically configured scan driver may account for user-selected scan 
parameters such that returned parameters allow the driver to configure itself 
based on these selected parameters and the scan peripheral's capabilities 
(App. Br. 6-7). 

Second, Appellants note that the Lo reference itself distinguishes scan 
drivers from scan parameters. Specifically, Appellants refer to Lo's 
descriptions of (1) scanner parameters in the form of options (e.g., 
resolution, brightness, and contrast), and (2) a scan driver which is "software 
which controls the image device," "analogous to a print driver," and is 
"usually written by the manufacturer of the scanner" (App. Br. 7; Reply Br. 
4). 
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Third, Appellants refer to the language of independent claims 1,8, 
and 13 on appeal as evidencing a distinction between scan drivers and scan 
parameters. Specifically, Appellants note that claim 1 calls for configuring a 
scan driver from "a set of pre-stored driving modules selected according to 
user set parameters in the scan job and capabilities. . . ." Appellants also refer 
to claim 8 which calls for "accepting parameters for a scan job... [and] 
linking driver modules," and claim 13 's recitation of "configuring a scan 
driver from a set of scan drive modules based upon[,]" among other things, 
"parameters included in the scan job" (App. Br. 8; emphasis added). 

The Examiner takes the position that the virtual TWAIN 6 driver 106 
and TWAIN driver 136 in Lo are configured by linking a set of pre-stored 
driving modules (i.e., linking each of the parameters so as to configure the 
virtual device driver). The Examiner also contends that "a number of 
different software [sic] are linked in order to perform the scan-to-application 
operation" in Lo, and that this functionality can be interpreted as linking a 
set of inherent, pre-stored driving modules to configure the TWAIN driver 
(Ans. 9-10). 

The issue before us, then, is whether Appellants have shown that the 
Examiner erred in finding that Lo anticipates independent claims 1, 8, and 
13. The issue turns on whether the Examiner's interpretation of the recited 
linking of a set of pre-stored driving modules (claim 1); linking driver 
modules from a stored set of driver modules (claim 8); or configuring a scan 
driver from a set of scan drive modules (claim 13) reasonably corresponds to 



6 The TWAIN standard defines a standard software protocol and application 
programming interface (API) for communication between software 
applications and image acquisition devices (Lo, col. 5, 11. 19-23, 41-46). 
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the functionality of the virtual TWAIN driver or TWAIN driver in Lo in 
light of the noted distinctions between scan drivers and scan parameters. For 
the reasons that follow, we find that it does not. 

Lo discloses a network-based image scanning system. As shown in 
Figures 2 and 3, image information is transmitted from a scanner 144 
connected to a server computer 130 to a client computer 102 via network 
120. The client computer includes an application program 104 comprising 
image-acquiring, image processing, and source manager software. The 
application program software communicates with the scanner server 
computer utilizing a virtual TWAIN driver 106 that interfaces with the 
application program (Lo, Abstract; col. 5, 11. 47-65; col. 6, 11. 41-65; Figs. 1- 
3). 

One implementation of this system (i.e., the "scan-to-application" 
process) is detailed in the flowchart of Figures 8A through 8E. As shown in 
Figure 8 A, the process begins by installing (1) the virtual TWAIN driver on 
the client computer, and (2) the network scanner software on the scanner 
server computer (Fig. 8A; Step 450). By virtue of this installed "virtual" 
driver on the client computer, the user at that computer can perform various 
functions (e.g., setting the scanner parameters) as if the scanner were 
directly connected thereto (Lo, col. 13, 11. 34-52). 

The user then selects the network scanner as the source of images 
using the pull-down menu shown in Figure 9 (Lo, Fig. 8A; Step 452). After 
the user selects the "Select Source" command 534, a subsequent menu (not 
shown) is displayed allowing the user to select from one or more device 
drivers. Then, the user requests the scanning operation to begin by selecting 
the "Acquire" command 536 (Lo, Fig. 8 A; Step 454), after which the client 
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computer determines if there is an available workgroup scanner on the 
network (Lo, col. 13, 1. 61 - col. 14, 1. 12; Figs. 8A, 9). 

If so, then communications is established between the client and the 
server (Lo, Fig. 8B; Steps 462-466). Then, upon request from the client 
computer, the server computer transmits a "read scanner parameters 
acknowledge command" to the client computer including the scanner 
parameters as attached data. Upon receipt, the client computer displays the 
scanner parameters using the virtual TWAIN device driver and allows the 
user to edit the scanner parameters at the client computer as shown in Figure 
10. As shown in that figure, the user can edit parameters such as resolution, 
brightness, and contrast using sliding graphic control buttons (Lo, col. 15, 11. 
34-47; Figs. 8B-8C (Steps 468-472); Fig. 10). If any parameters were 
changed, they are transmitted as attached data from the client computer to 
the server computer and stored at the server (Lo, col. 15, 11. 56-65; Fig. 8C 
(Steps 474-478)). 

Based on this functionality, we agree with Appellants that Lo does not 
reasonably disclose the recited linking of a set of pre- stored driving modules 
(claim 1); linking driver modules from a stored set of driver modules (claim 
8); or configuring a scan driver from a set of scan drive modules (claim 13). 

Notwithstanding our agreement with Appellants' arguments with 
respect to the critical distinction between scan drivers and scan parameters, 
we further note that we find the Examiner's interpretation of Lo's server 
computer as allegedly constituting a "scan peripheral" 7 problematic. Simply 



7 See, e.g., Ans. at 4 ("Lo discloses a program for interfacing a client 
computer (client computer 102) to one or more scan peripheral devices 
(scanner server 130)....") (emphasis added); see also Ans. at 12 (asserting 
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put, we disagree with the Examiner that the server computer 130 in Lo is a 
"scan peripheral" in light of the term's ordinary and customary meaning 
interpreted in light of the Specification. 

According to the Specification, "[a] scan peripheral is a scanner or 
multi-function device including a scanning function. Scan peripherals may 
be accessed through a server so that multiple users may use the same scan 
peripheral over a network, for example" (Spec. 1:7-11; emphasis added). 
This description, in our view, is tantamount to an implicit definition of the 
term "scan peripheral" 8 that not only clearly requires a device with scanning 
functionality, it also distinguishes such peripherals from their associated 
servers. Thus, while the server 130 in Lo is connected to a scanner 144, the 
server itself h simply not a "scan peripheral" under this definition. 

Indeed, the next paragraph in Appellants' Specification all but 

confirms this point. According to that paragraph: 

A scan peripheral server is typically realized in 
software that is installed in some type of general 
purpose computer system. . . Jet Direct® [external or 
internal server] devices can control multiple scan 
peripherals, including scanners and multi-function 
peripherals.. .A Jet Direct® server or other server 
that interfaces to multiple scan peripherals 
typically includes multiple drivers to facilitate 



that the peripheral (scanner server 130) in Lo stores a scan capability 
descriptor in its memory). 

8 See Phillips v. AWH Corp., 415 F.3d 1303, 1321 (Fed. Cir. 2005) (en banc) 
("[T]he specification is the single best guide to the meaning of a disputed 
term, and. . .acts as a dictionary when it expressly defines terms in the claims 
or when it defines them by implication.") (internal quotation marks and 
citations omitted). 
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control of scan jobs from different scan 
peripherals. 

(Spec. 1:13-2:3; emphasis added.) 

Furthermore, the claim language of the present application also clearly 
distinguishes a "scan peripheral" from a scan peripheral server. See, e.g., 
claim 8 (preamble reciting both "scan peripheral server" and "scan 
peripheral"); see also claim 12 (reciting a peripheral comprising an interface 
for connecting to a client machine or server). 

Based on this clear distinction between scan peripherals and scan 
peripheral servers, we find the only device in the embodiment of Figures 2 
and 3 of Lo that would reasonably correspond to a "scan peripheral" is the 
scanner 144 - not the server 130. 

In any event, we find the Examiner' s reliance on the functionality of 
either the virtual TWAIN driver 106 or the TWAIN driver 136 in Lo 
likewise problematic with respect to the scan driver limitations. 
Significantly, we fail to see how the TWAIN scan driver in Lo (virtual or 
otherwise) is configured from a set of stored drive modules based upon the 
capabilities indicated in the stored capability descriptor and scan parameters, 
let alone configured by linking a set of such stored modules, as claimed. 

Although the virtual TWAIN driver is installed at the client computer, 
it is merely installed at the beginning of the scanning process for the 
particular scanner used. Unlike the claimed invention, Lo's virtual driver is 
not configured for that job based upon the criteria recited in the claims, 
namely the stored capabilities and the scan parameters. While the virtual 
TWAIN driver is associated with other software as the Examiner indicates, 
the driver itself is simply not configured from drive modules based on the 
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recited criteria as claimed, let alone linking such drive modules. 9 Moreover, 
the fact that the user can edit scan job parameters associated with a given 
driver (e.g., brightness, contrast, etc.) in Lo hardly means that the driver 
itself is configured in the manner claimed. 

We note, however, that the user at the client computer does, in fact, 
select a particular driver immediately following selecting the "Select 
Source" command 534 from the pull-down menu in Figure 9 (i.e., via a 
subsequent menu that is not illustrated in Lo). See Lo, col. 14, 11. 1-4. To 
the extent that such a selection can be construed as "configuring" a scan 
driver from a set of "drive modules" (i.e., the various drivers presented for 
selection), such a configuration is simply not based on capabilities indicated 
by a capability descriptor and scan job parameters as claimed, let alone 
linking such modules in the manner claimed. 

For the foregoing reasons, Appellants have persuaded us of error in 
the Examiner's anticipation rejection of independent claims 1, 8, and 13. 
Therefore, we will not sustain the Examiner's rejection of those claims. 
Likewise, we will also not sustain claims 2-7 or claims 9-11, dependent on 
claims 1 and 8 respectively, for similar reasons. 



9 Although the Examiner refers to the Kuroshima reference as evidence that 
TWAIN drivers can be configured to operate by linking pre-stored modules 
based on parameters of operation, this reference was not relied upon in the 
rejection and is therefore not before us. See In re Hoch, 428, F.2d 1341, 
1342 n.3 (CCPA 1970) ("Where a reference is relied upon to support a 
rejection, whether or not in a 'minor capacity,' there would appear to be no 
excuse for not positively including the reference in the statement of the 
rejection."). 
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Independent Claim 12 

Regarding independent claim 12, Appellants argue that Lo does not 
disclose that the scan device 50 or 144 stores a capability descriptor or 
responds to queries regarding the same. Appellants emphasize that it is the 
server computer 130 -- not the scan device 144 -- that stores information 
(App. Br. 10-11). The Examiner takes the position that the peripheral 
corresponds to the server 130 and therefore stores in its memory a scan 
capability descriptor that is communicated responsive to queries requesting 
the same (Ans. 11-12). 

The issue before us, then, is whether Appellants have shown that the 
Examiner erred in finding that Lo's server 130 can be reasonably construed 
as a peripheral including a scanning capability, where the peripheral stores a 
scan capability descriptor and a controller that sends such a capability 
descriptor to the client machine or server, as claimed. 

We will not sustain the Examiner's rejection of claim 12 essentially 
for the reasons noted above in connection with the other independent claims. 
Our discussion regarding our disagreement with the Examiner that the server 
computer 130 in Lo is a "scan peripheral," interpreting the term's ordinary 
and customary meaning in light of the Specification, applies equally here 
and we incorporate that discussion here by reference. 

While it may be that the scanner 144 in Lo has some sort of 
"capability descriptor" stored in memory that could be communicated to a 
computer connected to the scanner (e.g., via a standard USB connection), the 
reference is simply silent regarding this possibility, and we decline to resort 
to speculation regarding such a feature. In any event, such possibilities are 
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not enough for anticipation, as the recited feature must be necessarily 
present in the reference, a requirement that is simply not met by Lo. 

For the foregoing reasons, Appellants have persuaded us of error in 
the Examiner's anticipation rejection of independent claim 12. Therefore, 
we will not sustain the Examiner's rejection of that claim. 

New Grounds of Rejection Under 37 C.F.R. § 41.50(b) 
Under 37 C.F.R. § 41.50(b), we enter the following new grounds of 
rejection: 

Claims 2-4 and 7 are rejected under 35 U.S.C. § 101 as being directed 
to non-statutory subject matter. 

For the reasons noted supra in connection with independent claim 1, 
claims 2-4 and 7 likewise do not recite statutory subject matter. Our 
previous discussion regarding claim 1 applies equally here and we therefore 
incorporate that discussion by reference. 

However, since claims 5 and 6 positively recite that the program is 
stored in a server or computer respectively, these claims at least nominally 
recite statutory subject matter (i.e., a program stored on a computer-readable 
medium) for the reasons indicated previously. 

DECISION 

We have sustained the Examiner's rejection of claim 1 under § 101, 
but have not sustained the Examiner's anticipation rejection of claims 1-13. 
Therefore, the Examiner's decision rejecting claims 1-13 is affirmed- in-part. 
We have also entered a new ground of rejection under 37 C.F.R. § 41.50(b) 
for claims 2-4 and 7. 
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This decision contains a new ground of rejection pursuant to 37 
C.F.R. § 41.50(b). This Section provides that "[a] new ground of rejection 
. . . shall not be considered final for judicial review." 

Section 41.50(b) also provides that the Appellants, WITHIN TWO 
MONTHS FROM THE DATE OF THE DECISION, must exercise one of 
the following two options with respect to the new ground of rejection to 
avoid termination of the appeal as to the rejected claims: 

(1) Submit an appropriate amendment of the claims so 
rejected or new evidence relating to the claims so 
rejected, or both, and have the matter reconsidered by 
the examiner, in which event the proceeding will be 
remanded to the examiner. . . . 

(2) Request that the proceeding be reheard under § 
41.52 by the Board upon the same record. ... 

No time period for taking any subsequent action in connection with this 
appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv). 
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AFFIRMED-IN-PART 
37 C.F.R.S 41.50(b) 
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